前言

想像一下：你家需要換燈泡。正常人怎麼做？

把電源關掉 → 換燈泡 → 再打開 → 一片漆黑到亮光中間會有個「斷電的瞬間」。

但如果你有兩組燈泡，新的燈已經先裝好，等到時機一到只要「啪！」地切換開關，就能瞬間亮起來，完全不影響生活。

在軟體世界裡，這種「不中斷切換」的方法，就叫做 藍綠部署 (Blue-Green Deployment)。

它的核心目標就是：
讓新版本能安全上線，同時保留舊版本作為保命符，一鍵切換、能上能退。

為什麼需要藍綠部署？

一般初學者的部署方式，通常長這樣：

1. 伺服器上直接 git pull / docker-compose up -d
2. 舊服務停掉 → 新服務啟動
3. 中間幾秒鐘，使用者看到的就是 502 Bad Gateway

這種「短暫停機」在 side project 沒差，但如果你是在跑一個 API、電商網站、甚至是支付系統，那一秒 downtime 可能就是幾十個用戶流失，甚至造成交易失敗。

問題在於：

• 舊服務和新服務之間沒有「重疊時間」
• 一旦新版本有 bug，回滾會很慢（要再重新 build / 部署一次）

這就像換燈泡時，全屋瞬間陷入黑暗，還可能踩到樂高積木。

藍綠部署的解法

藍綠部署的思路很簡單：

1. 藍環境 (Blue)： 現在線上跑的版本。
2. 綠環境 (Green)： 新版本已經在背景跑起來，但還沒切流量。
   當你確認綠環境健康（通過測試 / health check）後，只要 切換流量，所有使用者瞬間從藍 → 綠。

這樣做有幾個好處：

• 零停機：舊的還在跑，新的一切就緒才切換。
• 可回滾：如果新版本爆炸，只要把流量切回藍環境。
• 安全緩衝：你有兩套環境，不怕「上線就賭命」。

這就是「換燈泡不中斷」的秘密。

實作流程

今天我們不講 Kubernetes（因為對初學者太重），而是用 Docker Compose + Caddy 來模擬藍綠部署。

1. 準備兩個版本的 app

• myapp:blue（舊版本）
• myapp:green（新版本）

2. Caddy 作為反向代理

• 使用者只會透過 https://myapp.com 進來
• Caddy 負責決定流量要導到 Blue 還是 Green

myapp.com {
    reverse_proxy blue:8000
}

如果要切換：

myapp.com {
    reverse_proxy green:8000
}

3. 健康檢查

在 Green 環境啟動時，先用 /healthz 確認服務狀態。只有「200 OK」時，Caddy 才會改指向 Green。

4. 切換 & 回滾

• 切換到 Green：流量瞬間導向新版本。
• 如果 Green 有問題 → 把 Caddy 改回指向 Blue，立即回滾。

效果：
使用者只會看到服務一直可用，完全感受不到背後你在換燈泡。

藍綠部署只是「不中斷上線」的一種方法，還有其他策略：

• 滾動更新 (Rolling Update)： 一次更新一部分容器，逐步替換。
• 金絲雀發布 (Canary Release)： 先讓 5% 使用者試新版本，如果沒炸，再逐步擴大到 100%。

這些都是為了平衡「速度」與「風險」。

大公司可能會混合使用（例如先 Canary → 再 Blue-Green → 最後 Rolling）。
而對初學者來說，理解 Blue-Green 已經能大大提升部署思維。

結論

藍綠部署的精神，就是：

• 不要直接把新版本硬塞上去 → 造成 downtime
• 準備兩套環境，確認新版本健康後再切換
• 永遠留有「回頭路」：新版本爆炸，立刻切回舊的

生活裡換燈泡不中斷，軟體裡版本上線不中斷。
這就是 DevSecOps 裡「交付信任」的最佳實踐之一。

所以下次你在佈署專案時，不妨問自己一句：
「我這是在換燈泡，還是在把整棟房子先拉掉電源？」